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Abstract 


This memo provides guidelines and Best Current Practice for operating 
DNS in a world where queries and responses are carried in a mixed 
environment of IPv4 and IPv6 networks. 


1. Introduction to the Problem of Name Space Fragmentation: 
following the referral chain 


A resolver that tries to look up a name starts out at the root, and 
follows referrals until it is referred to a name server that is 
authoritative for the name. If somewhere down the chain of referrals 
it is referred to a name server that is only accessible over a 
transport which the resolver cannot use, the resolver is unable to 
finish the task. 


When the Internet moves from IPv4 to a mixture of IPv4 and IPv6 it is 
only a matter of time until this starts to happen. The complete DNS 
hierarchy then starts to fragment into a graph where authoritative 
name servers for certain nodes are only accessible over a certain 
transport. The concern is that a resolver using only a particular 
version of IP and querying information about another node using the 
same version of IP can not do it because somewhere in the chain of 
servers accessed during the resolution process, one or more of them 
will only be accessible with the other version of IP. 


With all DNS data only available over IPv4 transport everything is 


simple. IPv4 resolvers can use the intended mechanism of following 
referrals from the root and down while IPv6 resolvers have to work 
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through a "translator", i.e., they have to use a recursive name 
server on a so-called "dual stack" host as a "forwarder" since they 
cannot access the DNS data directly. 


With all DNS data only available over IPv6 transport everything would 
be equally simple, with the exception of IPv4 recursive name servers 
having to switch to a forwarding configuration. 


However, the second situation will not arise in the foreseeable 
future. Instead, the transition will be from IPv4 only to a mixture 
of IPv4 and IPv6, with three categories of DNS data depending on 
whether the information is available only over IPv4 transport, only 
over IPv6 or both. 


Having DNS data available on both transports is the best situation. 
The major question is how to ensure that it becomes the norm as 
quickly as possible. However, while it is obvious that some DNS data 
will only be available over v4 transport for a long time it is also 
obvious that it is important to avoid fragmenting the name space 
available to IPv4 only hosts. For example, during transition it is 
not acceptable to break the name space that we presently have 
available for IPv4-only hosts. 


2. Terminology 


The phrase "IPv4 name server" indicates a name server available over 
IPv4 transport. It does not imply anything about what DNS [1,2] data 
is served. Likewise, "IPv6 [4,5,6] name server" indicates a name 
server available over IPv6 transport. The phrase "dual-stack name 
server" indicates a name server that is actually configured to run 
both protocols, IPv4 and IPv6, and not merely a server running on a 
system capable of running both but actually configured to run only 
one. 


3. Policy Based Avoidance of Name Space Fragmentation 


Today there are only a few DNS "zones" on the public Internet that 
are available over IPv6 transport, and most of them can be regarded 
as "experimental". However, as soon as the root and top level 
domains are available over IPv6 transport, it is reasonable to expect 
that it will become more common to have zones served by IPv6 servers. 


Having those zones served only by IPv6-only name server would not be 
a good development, since this will fragment the previously 
unfragmented IPv4 name space and there are strong reasons to find a 
mechanism to avoid it. 
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The recommended approach to maintain name space continuity is to use 
administrative policies, as described in the next section. 


4. DNS IPv6 Transport recommended Guidelines 


In order to preserve name space continuity, the following 
administrative policies are recommended: 


- every recursive name server SHOULD be either IPv4-only or dual 
stack, 


This rules out IPv6-only recursive servers. However, one might 
design configurations where a chain of IPv6-only name server 
forward queries to a set of dual stack recursive name server 
actually performing those recursive queries. 


- every DNS zone SHOULD be served by at least one IPv4-reachable 
authoritative name server. 


This rules out DNS zones served only by IPv6-only authoritative 
name servers. 


Note: zone validation processes SHOULD ensure that there is at least 
one IPv4 address record available for the name servers of any child 


delegations within the zone. 


5. Security Considerations 


The guidelines described in this memo introduce no new security 
considerations into the DNS protocol or associated operational 
scenarios. 
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